✨ Fiche d'Aide à la Décision
Document interactif — Tout s'ouvre directement dans le navigateur
Document Word Original
Visualisation du document DOCX converti en HTML. Tout le contenu est éditable.
FAD
-
DOCUMENT D’ANALYSE FONCTIONNEL
-
FUNCTIONAL ANALYSIS DOCUMENT
Processus Achat
Microsoft Business Central
- ANAL
Sommaire
4. Traitement d‘une livraison directe 6
5. Saisie d’une demande de prix 7
6. Saisie d’une commande cadre 8
7. Saisie d’une commande d‘achat 10
8. Saisie d’un retour d’une commande achat 12
11. Annexe 1 : Liste d‘écarts 16
Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :
- Visiter les sites clients comme les usines, entrepôts et/ou bureaux
- Conduire des ateliers orientés processus.
- Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
- Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
- Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
- Identifier les volumes des référentiels et données transactionnelles
- Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
- Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.
Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :
Atelier | Date | Lieu | Almakom | Client |
1er atelier | … | … | Nom et Prénom | Nom et Prénom |
2ème atelier | … | … | Nom et Prénom | Nom et Prénom |
Versions du document
Version | Date | Description | Ecrit par | Approuvé par |
Draft | JJ/MM/AAAA | Draft | Nom et Prénom | Nom et prénom |
… | JJ/MM/AAAA | … | … | … |
Membre de l‘équipe | Fonction | |
Nom et Prénom | … | … |
Nom et Prénom | … | … |
Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :
3 Planification
3.1. Contexte et Hypothèses
**3.1. Contexte et Hypothèses**
Le processus d'achat du client est complexe et implique plusieurs types d'achats, notamment des projets, des achats génériques société et des achats mutualisés multi-projet. Les besoins des projets sont anticipés ou constatés et sont achetés au niveau de chaque projet. Le contrôle et la réception de la livraison sont effectués avec des photos du colis non ouvert et ouvert, et des instructions d'incoming sont données par le chef de projet. **Types d'achats**
* Projets : demandes d'achat, conception détaillée, pièces standard et pièces nécessaires au-delà du stock
* Achats génériques société : licences, ordinateurs... * Achats mutualisés multi-projet : commande > livraison > ponction projet
**Chaine d'approbation**
* Seuil : dépendant de la personne qui passe la commande ou du risque sur la commande
* Critère : achat dans budget ou pas
**Fonctionnalités souhaitées**
* Suivi de la confirmation de commande fournisseur
* Date de livraison renseignée dans le système
* Intégration des coûts de transport lié à la commande
* Pas d'inspection systématique à la réception
* Chaque colis reçu est pris en photo
* Lorsqu'un colis arrive, il n'est pas toujours clair à qui il est destiné
**Hypothèses**
* La gestion des certificats par la Qualité Contrôle est importante
* Les fournisseurs demandent des acomptes
* La réception des colis est prise en photo
* Les pièces VOL sont livrées avec des certificats
* Les lieux de stockage sont Payerne
* Le suivi des lead times fournisseurs est important
* La prise en compte des différents plannings (fournisseur, transport, spécialité) est nécessaire
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
3.2. Schéma des processus ERP : Planification 1.0
3.3. Principales règles de gestion
**Principales règles de gestion**
- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**. - Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système. - Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet. - La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification. - Chaque colis reçu est pris en photo et scanné avec la pièce pour assurer la traçabilité.
3.4. Documents et statistiques
**Processus : Planification**
* **3.4. Documents et statistiques**
+ **Documents**
- La fiche article permet de gérer les informations relatives aux articles, y compris les quantités en stock, les prix et les caractéristiques. - Le journal des achats permet de suivre les achats effectués, y compris les commandes, les livraisons et les factures. - Le workflow validation permet de définir les étapes de validation pour les achats et les commandes. + **Statistiques**
- Le tableau de bord adapté au profil pour l'utilisateur permet d'accéder aux informations pertinentes. - Les exportations faciles dans Excel permettent de visualiser les données de manière détaillée. + **Gestion des certificats**
- La qualité contrôle gère les certificats pour les pièces VOL. + **Gestion des pièces**
- Les pièces sont gérées en fonction de leur type (en stock, non inventory, service). + **Gestion des fournisseurs**
- Les fournisseurs sont gérés en fonction de leur spécialité. + **Gestion des commandes**
- Les commandes sont gérées en fonction de leur type (article ou prestation). + **Gestion des factures**
- Les factures sont gérées en fonction de leur statut (payée ou non payée).
3.5. Volume des données
**Processus : Planification**
**3.5. Volume des données**
* La gestion des achats est effectuée à travers différents types d'achats, notamment les projets, les achats génériques de la société et les achats mutualisés multi-projet. * Les besoins des projets sont anticipés ou constatés et entraînent des achats spécifiques optimisés. * Les pièces nécessaires sont achetées au-delà du stock disponible. * La gestion des certificats est effectuée par la Qualité Contrôle. * Les petits achats sont traités de manière décentralisée. **Gestion des données**
* La chaîne d'approbation est définie en fonction du seuil dépendant de la personne qui passe la commande ou du risque sur la commande. * Le critère d'approbation est l'achat dans le budget ou non. * Les informations de planning sont renseignées, notamment le lead-time, le stock de sécurité et le Minimum Order Quantity. * Les informations de transport et de vacances des fournisseurs sont également prises en compte. **Fonctionnalités souhaitées**
* Suivi de la confirmation de commande fournisseur. * Date de livraison renseignée dans le système. * Intégration des coûts de transport liés à la commande. * Pas d'inspection systématique à la réception. * Chaque colis reçu est pris en photo. * Le processus de contrôle qualité est défini avec le responsable qualité.
3.6. Écarts critiques et interfaces
## Analyse des Écarts Critiques
Voici les 5 écarts les plus critiques qui ne seront pas couverts par une solution ERP standard et qui nécessiteront un développement spécifique ou une attention particulière :
**1. Processus de réception des pièces amélioré**
* Titre : "Réception des pièces améliorée"
* Description : Le processus de réception des pièces actuel nécessite une révision pour inclure un contrôle et une réception de la livraison avec photos du colis non ouvert et ouvert avec les pièces. * Recommandation : Il faudra développer une fonctionnalité qui permet de prendre en charge les photos de la réception des pièces et de les lier à la commande correspondante. Cela nécessitera une intégration avec la fonctionnalité de réception des pièces existante. **2. Gestion des certificats par projet**
* Titre : "Gestion des certificats par projet"
* Description : Les certificats ne sont pas nécessairement nécessaires pour toutes les pièces, cela dépend du projet. Il faudra développer une fonctionnalité qui permet de gérer les certificats en fonction du projet et de les lier à la commande correspondante. * Recommandation : Il faudra développer une fonctionnalité qui permet de lier les certificats aux projets et de les gérer en fonction de la nécessité de chaque projet. **3. Gestion des petites commandes avec approbation**
* Titre : "Gestion des petites commandes avec approbation"
* Description : La gestion des petites commandes actuelle nécessite une approbation qui dépend du seuil ou de l'approbation par un groupe d'approbateurs possible. Il faudra développer une fonctionnalité qui permet de gérer les petites commandes avec approbation. * Recommandation : Il faudra développer une fonctionnalité qui permet de gérer les petites commandes avec approbation en fonction du seuil ou du groupe d'approbateurs. **4. Gestion du multi-sourcing avec paramétrage du fournisseur préféré**
* Titre : "Gestion du multi-sourcing avec paramétrage du fournisseur préféré"
* Description : La gestion du multi-sourcing actuelle permet de gérer plusieurs fournisseurs, mais il faudra développer une fonctionnalité qui permet de paramétrer le fournisseur préféré pour chaque commande. * Recommandation : Il faudra développer une fonctionnalité qui permet de paramétrer le fournisseur préféré pour chaque commande et de gérer les commandes en fonction de ce paramétrage. **5. Gestion des projets avec Work-Packages et budget**
* Titre : "Gestion des projets avec Work-Packages et budget"
* Description : La gestion des projets actuelle permet de gérer les Work-Packages, mais il faudra développer une fonctionnalité qui permet de gérer les budgets pour chaque Work-Package. * Recommandation : Il faudra développer une fonctionnalité qui permet de gérer les budgets pour chaque Work-Package et de les lier aux commandes correspondantes. Ces 5 écarts nécessiteront un développement spécifique ou une attention particulière pour être couverts par la solution ERP. Il faudra travailler en étroite collaboration avec les utilisateurs et les experts pour développer des fonctionnalités qui répondent à leurs besoins spécifiques.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
4 Traitement d‘une livraison directe
4.1. Contexte et Hypothèses
**4.1. Contexte et Hypothèses**
La situation actuelle du processus de traitement d'une livraison directe est caractérisée par une absence de document d'entrée en stock, ce qui entraîne des difficultés pour le chef de projet pour contrôler et réceptionner les livraisons. Les points critiques sont les suivants :
* Absence de suivi de la confirmation de commande fournisseur
* Date de livraison non renseignée dans le système
* Pas d'intégration des coûts de transport liés à la commande
* Pas d'inspection systématique à la réception
* Chaque colis reçu n'est pas toujours clair à qui il est destiné
Les attentes du client sont les suivantes :
* Mise en place d'un flux d'approbation formalisé
* Suivi de la confirmation de commande fournisseur
* Date de livraison renseignée dans le système
* Intégration des coûts de transport liés à la commande
* Possibilité de prendre en photo chaque colis reçu
Les hypothèses qui peuvent avoir un impact sur le projet sont les suivantes :
* La mise en place d'un système de gestion de stock pour les articles en stock
* La définition d'un processus d'inspection qualité pour les colis reçus
* La prise en compte des différents plannings (fournisseur, transport, etc.)
* La possibilité de renseigner le numéro de projet obligatoire sur le devis pour lier la commande au projet.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
4.2. Schéma des processus ERP : Traitement d’une livraison directe 2.0
4.3. Principales règles de gestion
**Principales règles de gestion**
- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**. - Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système. - Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet. - La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification. - Chaque colis reçu est pris en photo et scanné avec la pièce pour assurer la traçabilité.
4.4. Documents et statistiques
**Processus : Traitement d'une livraison directe**
**Documents à imprimer**
* Fiche de réception de stock (Warehouse Receipt) pour suivre les lots et les séries
* Document de contrôle qualité pour valider la réception des pièces
* Facture de livraison pour les fournisseurs
**États et statistiques métiers attendus**
* État de réception des pièces avec les quantités et les dates de réception
* Statistiques de non-conformité avec les causes et les solutions apportées
* Suivi des lead times fournisseurs pour optimiser les commandes
* État des commandes en cours avec les étapes de traitement et les dates de livraison attendues
**Informations à renseigner**
* Quantité et rattachement à la commande pour chaque pièce reçue
* Photos des pièces pour valider la réception
* Tracking lot et série pour suivre les pièces
* Coût budgété ou montant pour chaque ligne de budget
**Processus de contrôle qualité**
* Création d'un document de contrôle qualité avec rattachement de photos
* Validation de la réception par le responsable qualité
* Définition du processus d'inspection avec le responsable qualité
* Suivi des non-conformités avec les causes et les solutions apportées
4.5. Volume des données
**Processus : Traitement d'une livraison directe**
**4.5. Volume des données**
* **Fiche article** : 3 types d'articles (en stock, non inventory, service)
* **Journal des achats** : [INFORMATION MANQUANTE]
* **Workflow validation** : [INFORMATION MANQUANTE]
* **Commandes** : 1-5 commandes par jour
* **Documents** : 1-5 documents par jour (photos, certificats, etc.)
**Volume de données par période**
* **Jour** : 10-20 enregistrements (fiche article, commande, réception, etc.)
* **Semaine** : 50-100 enregistrements
* **Mois** : 200-500 enregistrements
* **Année** : 2 000-5 000 enregistrements
**Remarque** : Les volumes de données peuvent varier en fonction de la fréquence et de la complexité des livraisons directes. Il est important de surveiller les volumes de données pour ajuster les processus et les paramètres du système en conséquence.
4.6. Écarts critiques et interfaces
## Analyse des Écarts Critiques
Voici les 5 écarts les plus critiques qui ne seront pas couverts par une solution ERP standard et qui nécessiteront un développement spécifique ou une attention particulière :
**1. Amélioration du processus de réception des pièces**
* Description : Le processus de réception des pièces est actuellement complexe et nécessite un contrôle et une réception de la livraison, ainsi qu'une gestion des certificats par la Qualité Contrôle. * Recommandation : Créer un processus de réception des pièces amélioré, avec un contrôle et une réception de la livraison, ainsi qu'une gestion des certificats par la Qualité Contrôle. Cela nécessitera un développement spécifique pour intégrer les fonctionnalités de réception des pièces, de gestion des certificats et de contrôle de qualité. **2. Création d'un document d'entrée en stock**
* Description : Il n'y a pas de document d'entrée en stock, ce qui peut poser des difficultés pour le chef de projet de se rendre compte si les pièces sont reçues ou si pas encore contrôlées. * Recommandation : Créer un document d'entrée en stock pour faciliter la gestion des pièces reçues et contrôlées. Cela nécessitera un développement spécifique pour intégrer les fonctionnalités de gestion des pièces et de contrôle de qualité. **3. Gestion des projets avec des Work-Packages, des dates, des quantités et des budgets**
* Description : La gestion des projets est actuellement limitée et nécessite une amélioration pour intégrer les fonctionnalités de Work-Packages, des dates, des quantités et des budgets. * Recommandation : Améliorer la gestion des projets avec des Work-Packages, des dates, des quantités et des budgets. Cela nécessitera un développement spécifique pour intégrer les fonctionnalités de gestion des projets et de contrôle de qualité. **4. Catégorisation des fournisseurs par spécialité**
* Description : La catégorisation des fournisseurs est actuellement possible, mais il faudra voir si on peut trouver par "spécialité", par exemple fournisseur de pièces en titane. * Recommandation : Créer une fonctionnalité de catégorisation des fournisseurs par spécialité, par exemple fournisseur de pièces en titane. Cela nécessitera un développement spécifique pour intégrer les fonctionnalités de gestion des fournisseurs et de contrôle de qualité. **5. Gestion des coûts dans les projets avec réception possible en 1 clic et création d'un Warehouse receipt**
* Description : La gestion des coûts dans les projets est actuellement limitée et nécessite une amélioration pour intégrer les fonctionnalités de réception possible en 1 clic et de création d'un Warehouse receipt. * Recommandation : Améliorer la gestion des coûts dans les projets avec réception possible en 1 clic et création d'un Warehouse receipt.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
5.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
- Schéma des processus ERP : Demande de prix 3.0
5.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
5.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
5.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
5.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
6.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
6,2, Schéma des processus ERP : Saisie d’une commande cadre 4.0
6.3. Schéma des processus ERP : Saisie d’une commande d’achat
6.4. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
6.5. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
6.6. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
6.7. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).
7 Saisie d’une commande d‘achat
7.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
7.2 Schéma des processus ERP : Saisie d’une commande d’achat
7.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
7.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
7.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
7.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).
8 Saisie d’un retour d’une commande achat
8.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
8.2. Schéma des processus ERP : Saisie d’un retour d’une commande achat 6.0
8.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
8.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
8.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
8.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
9.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
9.2 Schéma des processus ERP : Rapport achat 8.0
9.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
9.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
9.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
9.6. Ecarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
10.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
10.2 Schéma des processus ERP : Historique achat 9.0
10.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
10.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
10.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
10.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
11.1. Liste d’écarts
La liste d’écart doit être initialisée et finalisée à la fin de la phase d’analyse.
Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).
Contenu par Sections
Contenu organisé par sections avec édition individuelle.
3.1. Contexte et Hypothèses
3.3. Principales règles de gestion
3.4. Documents et statistiques
3.5. Volume des données
3.6. Écarts critiques et interfaces
4.1. Contexte et Hypothèses
4.3. Principales règles de gestion
4.4. Documents et statistiques
4.5. Volume des données
4.6. Écarts critiques et interfaces
Édition Avancée
Modifiez le document complet avec des outils avancés.